A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.
In an SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load,[1] or partial changes are performed loading new code on demand from the web server, usually driven by user actions. The page does not automatically reload during user interaction with the application, nor does control transfer to another page. Updates to the displayed page may or may not involve interaction with a server.
The term single-page application was coined by Steve Yen in 2005, though the concept was discussed at least as early as 2003.[2]
Contents |
The way traditional web applications work causes disruption in the user experience and workflow.
Traditional web applications work by reloading the entire web page. In order to advance through a workflow, the user interacts with page elements (such as hyperlinks and form submit buttons) that cause the browser to issue a request to the server for a completely new page.
User experience: Continual page redraws disrupt the user experience because the network latencies cannot be hidden from the user.[3] There is typically a perceivable transitional jolt from one page to the next. The next page's data is retrieved from the server, the old page is unloaded, and the new page is rendered to screen.
Stable UI affordances, such as toolbars, navigation elements, database query results and so forth, continually disappear and reappear.
Performance: The complete page reload that occurs on each user interaction results in unnecessary re-transmission of data over the wire. This can make the overall performance of the web-site, when the entire session is taking into account, slower.
SPA's address these issues by requiring no page reload by the browser during an application session. All user interaction and changes of the application state are handled in the context of a single Web document.[4]
The user experience becomes more continuous and fluid, and network latencies can be hidden more easily.
There are various techniques available that enable the browser to retain a single page even when the application requires server communication.
The most prominent technique currently being used is Ajax.[1] Predominantly using the XMLHttpRequest object from JavaScript, other AJAX approaches include using IFRAME or script HTML elements. Popular libraries like JQuery, that normalize AJAX behavior across browsers from different manufacturers, have further popularized the AJAX technique.
Asynchronous calls to the server may also be achieved using browser plug-in technologies such as Java applets, Flash or Silverlight.
Requests to the server typically result in either raw data (JSON) or new HTML being returned. In the case where HTML is returned by the server, JavaScript on the client updates a partial area of the DOM (Document Object Model). When raw data is returned, often times a client-side template is used to translate the raw data into HTML, which is then used to update a partial area of the DOM.
An SPA moves client-side logic from the server to the client. This results in the role of the web server evolving into a pure data API or web service. This architectural shift has, in some circles, been coined "Thin Server Architecture" to highlight that complexity has been moved from the server, to the client, with the argument that this ultimately reduces overall complexity of the system.[5]
The server keeps the necessary state in memory of the client state of the page, by this way when any request hits the server (usually user actions), the server sends the appropriated HTML and/or JavaScript with the concrete changes to bring the client to the new desired state (usually adding/deleting/updating a part of the client DOM), in the same time the state in server is updated accordingly. Most of the logic is executed in server and usually HTML is also rendered in server, in some way the server simulates a web browser receiving events and performing delta changes in server state automatically propagated to client. This approach needs more server memory and server processing, advantages are a simplified development model because the application is usually fully coded in server, data and UI state in server are shared in same memory space with no need of custom client/server communication bridges and is more secure because any client request/event can be easily ignored if there is no corresponding UI handle in server (for instance when the client request states a client button has been clicked and there is no such UI handle of this button in server). the client is like a sophisticated terminal of the server.
Some SPAs may be executed from a local file using the file URI scheme. This gives users the ability to download the SPA from a server and run the file from a local storage device, without depending on server connectivity. If such an SPA wants to store and update data, it must be self-modifying. That is, the SPA must be capable of writing itself to disk, including a representation of the state that is to be persisted. These applications benefit from advances available with HTML5, particularly Web Storage.
Because the SPA is an evolution away from the classical page-redraw model that browsers were originally designed for, some new challenges have emerged. Each of these problems have an effective solution[3] with:
Because of the lack of JavaScript execution on crawlers of all popular Web search engines, SEO has historically presented a problem for public facing websites wishing to adopt the SPA model.
Google currently crawls URLs containing hash fragments starting with #!,.[9] This allows the use of hash fragments within the single URL of an SPA. Special behavior must be implemented by the SPA site to allow extraction of relevant metadata by the search engine's crawler.
For search engines that do not support this URL hash scheme, the hashed URL's of the SPA remain invisible.
It's worth noting that SPA's are commonly not used in a context where search engine indexing is either a requirement, or desirable. Use cases include applications that surface private data hidden behind an authentication system. In the cases where these applications are consumer products, often a classic "page redraw" model is used for the applications landing page and marketing site, which provides enough meta data for the application to appear as a hit in a search engine query. Blogs, support forums, and other traditional page redraw artefacts often sit around the SPA that can seed search engines with relevant terms.
With an SPA being, by definition, "a single page", the model breaks the browser's design for page history navigation using the Forward/Back buttons . This presents a usability impediment when a user presses the back button, expecting the previous screen state within the SPA, but instead the application's single page unloads and the previous page in the browser's history is presented.
The traditional solution for SPA's has been to change the browser URL's hash fragment identifier in accord with the current screen state. This can be achieved with JavaScript, and causes URL history events to be built up within the browser. As long as the SPA is capable of resurrecting the same screen state from information contained within the URL hash, the expected back button behavior is retained.
To further address this issue, the HTML5 specification has introduced pushState and replaceState providing programmatic access to the actual URL and browser history.
An SPA is fully loaded in the initial page load and then page regions are replaced or updated with new page fragments loaded from the server on demand. To avoid excessive downloading of unused features, an SPA will often progressively download more features as they become required, either small fragments of the page, or complete screen modules.
In this way an analogy exists between "states" in an SPA and "pages" in a traditional web site. Because "state navigation" in the same page is analogous to page navigation, in theory any page based web site could be converted to single-page replacing in the same page only the changed parts result of comparing consecutive pages in a non-SPA.
The SPA approach on the web is similar to the Single Document Interface (SDI) presentation technique popular in native desktop applications.